Some of the following assumptions are obtained rom line 390 of playerdb.cpp in emptool.

The 'playlist' database is a list of FILEID's, one right after another.

The 'length' tag for a playlist in the "database" file refers to number of FILEIDs for tunes immediately following that particular playlist's FILEID ('length'/sizeof(FILEID))

At this point I guess my question is, how does the playlist file and the database file match up? I figure the playlist entries in the database file appear in the same order as those in the playlists file. However how does a song FILEID in the playlists file match up to a 'tune' entry in the database file? Not all tunes in the database have a 'fileid' tag, and even the ones that do don't really match up to real FILEIDs. And songs don't really appear in the database file immediately following their proper playlist.

Greg

That one had me puzzling for long, as I thought the filenames had no direct relation to the database entries. I started mapping entries in the database to filenames and saw iterating filenames with some gaps between them.
I already discovered the MakeFid macro : record_nr << 4 | FILE_TYPE
but I thought that would make the ordering of filenames iterating without gaps...

Then the quarter fell. TAG-INFO OF DELETED FILES IS STILL IN THE DATABASE.

So the MakeFid macro works : record_nr << 4 | FILE_TYPE
or in other terms : ( record_nr * 16 ) + FILE_TYPE

recordnumbering of playlists/tunes starts at 16, as the root-playlist is named 10[01]

So what this means is I feed this MakeFid macro the index to the desired item in the database, and the type of the request (i.e. a Tune) and it returns the File ID for the requested tune?

Three more questions arise from this:
1. Does the GetFidNumber macro return an index into the database given a File ID, as it appears? This seems to me as the only method of making this a bidirectional system of operation.
2. Are File IDs unique across both drives? From what I can tell, not all tunes in the database have a tag to tell you whether they are located on Drive 1 or Drive 0.
3. Would it be advisable to clear out these deleted entries in the database once in a while? Presumably I would delete the database, tags, and playlists files in order to force Emplode to rebuild them.

Greg

1. Does the GetFidNumber macro return an index into the database given a File ID, as it appears? This seems to me as the only method of making this a bidirectional system of operation.

given a file couple : 89d1/89d0, you can get the database entry by shifting 4 places to the right, leaving 0x89d. Substracting 16 from that leaves 0x88d, so the file's tag-info should be at entry 2189 of the database

2. Are File IDs unique across both drives? From what I can tell, not all tunes in the database have a tag to tell you whether they are located on Drive 1 or Drive 0.

They are unique. Files are searched on both drives. Files are written on the disk that has most free space available.

3. Would it be advisable to clear out these deleted entries in the database once in a while? Presumably I would delete the database, tags, and playlists files in order to force Emplode to rebuild them.

Also my idea at first. Then I started hypotheticalizing :
What if I decided to upload all Monty Python one-liners as single MP3's on my empeg, which could account for more than 25.000 database-entries.
Let's presume the tag data for every file is 200 bytes on average. So 25000 * 200 bytes = 2500000bytes = 4.76Mb. If I decide a week after to delete every MP MP3 and replace it with some multiple-hour-long classical masterpieces, about 150, I would have a lot of unused database-space : (25000-150)* 200 = 4.74 MB.
It shouldn't be much of a problem in emplode or in terms of disk-usage, but I hope the player-app deletes the unused entries after reading the database...

Guys I have a question.
Is what you are doing with the Playlist database, useful/relevant to This Thread about exposing the current playlist the palyer app is using [which is afterall persisted to disk between shutdowns].

I would guess that the players current playlist, is simply a list of FIDs, in which case, using your code to 'flesh out' the FIds into a full tracklist ala CharcoalGrays XML playlist would be useful.

Also, do you guys have any knowledge of where on disks the players current playlist is stored?

From what I understand about that other thread, they're talking more about the player's active queue of tracks. Here we're talking about the available playlists in the player's database.

If I've misunderstood, let me know

Greg

But the two will be linked, in that the list of currently playing tracks, will be a list of FIDs will it not.
What you are doing is reading a list of FIDS (admittedly, from the playlists database) and then turning it into detailed song information (e.g. title, source etc).

Therefore you are doing some of what the other thread requires already I think.

Ok, here's me trying to think up on Frank's level, and I'm almost getting the picture, but I keep running into road blocks.

For testing purposes, I'm using your code posted earlier, about reading the database file. Every time we see it's the end of an entry: "---------" I'll display a counter, then increment it. For instance, "Unattached Items" is the third item returned from the database file, so it's given DB Index == 3.

So far so good. I travel down the list to a section I know and want to test.

I find a tune in our list at DB Index 3262. I know for a fact that it's FID on the drive is E2C0. E2C0 shifted right 4 places is E2C, subtract 16 and we get E1C which is 3612 ... exactly 350 off from our index we want. Trying this on another tune gives us another variance of 350. Working in reverse, from our index to a FID, I get CCE0 ...

Where would this variance come from, and would it be wrong to assume that I would get a similar variance by running the same code on a different database? (i.e. make it a constant and use it in the calculation)

Greg

In that case, yes. I'm taking a FID and getting song information from the player's database ... or I'm getting a playlist from the database, finding all the associated FIDs and their associated song informations (weird plural, huh?).

Greg

here's a piece of code which matches the fid files to the database.
Only the root-playlist doesn't match, all others do... :

#include <fcntl.h>

#include <stdio.h>



#define DBFILE "/empeg/var/database"

#define TAGFILE "/empeg/var/tags"



int main(int argc, char *argv[])

{

        unsigned char   c;

        char    s[2048];

        char    *tags[20];

        int     i,end_entry,db_index;

        FILE    *fp,*fp2;



        fp=fopen(TAGFILE, "rb");

        i=0;

        while (fgets(s,sizeof(s), fp) != NULL) {

                s[strlen(s)-1]='\0';

                tags[i++]=(char *)strdup(s);

        }

        fclose(fp);

        i=0;

        db_index=16;

        fp=fopen(DBFILE, "rb");

        while ( fread(&c,1,1,fp) > 0 ) {

                if ( c == 0xFF ) {

                        end_entry=1;

                } else {

                        if (end_entry) {

                                printf("--------------------------------\n\n");

                                i=db_index << 4 | 1;

                                printf("****************************\n");

                                printf("opening /drive0/fids/%x\n",i);

                                sprintf(s,"/drive0/fids/%x",i);

                                fp2=fopen(s, "rb");

                                if ( fp2 != NULL ) {

                                        while (fgets(s,sizeof(s), fp2) != NULL) {

                                                printf("%s",s);

                                        }

                                        fclose(fp2);

                                }

                                printf("****************************\n");

                                end_entry=0;

                                db_index++;

                        }

                        i=c;

                        fread(&c,1,1,fp);

                        fread(s,1,c,fp);

                        s[c]='\0';

                        printf("%s : %s\n",tags[ i ],s);

                }

        }

        fclose(fp);

}

Correction :
After some deletions/uploads, I see some inconsistencies in the algorithm, as Greg also noticed. It seems that every 0xFF is a record seperator. It makes sense, as the db_index now starts at 0...
See the new code :

#include <fcntl.h>

#include <stdio.h>



#define DBFILE "/empeg/var/database"

#define TAGFILE "/empeg/var/tags"



int main(int argc, char *argv[])

{

        unsigned char   c;

        char    s[2048];

        char    *tags[50];

        int     i,end_entry,db_index;

        FILE    *fp,*fp2;



        fp=fopen(TAGFILE, "rb");

        i=0;

        while (fgets(s,sizeof(s), fp) != NULL) {

                s[strlen(s)-1]='\0';

                tags[i++]=(char *)strdup(s);

        }

        fclose(fp);

        i=0;

        db_index=0;

        fp=fopen(DBFILE, "rb");

        while ( fread(&c,1,1,fp) > 0 ) {

                if ( c == 0xFF ) {

                        end_entry=1;

                        db_index++;

                } else {

                        if (end_entry) {

                                printf("--------------------------------\n\n");

                                i=db_index << 4 | 1;

                                printf("****************************\n");

                                printf("opening /drive0/fids/%x\n",i);

                                printf("index: %d\n",db_index);

                                sprintf(s,"/drive0/fids/%x",i);

                                fp2=fopen(s, "rb");

                                if ( fp2 != NULL ) {

                                        while (fgets(s,sizeof(s), fp2) != NULL) {

                                                printf("%s",s);

                                        }

                                        fclose(fp2);

                                }

                                printf("****************************\n");

                                end_entry=0;

                        }

                        i=c;

                        fread(&c,1,1,fp);

                        fread(s,1,c,fp);

                        s[c]='\0';

                        printf("%s : %s\n",tags[ i ],s);

                }

        }

        fclose(fp);

}

Thank you so much for your help Frank!

Greg

This one is a winner! The fids and database entries match up perfectly!

Greg

TAG-INFO OF DELETED FILES IS STILL IN THE DATABASE

Not really.

It seems that every 0xFF is a record seperator.

Yes. So two consecutive FF's mean that there's a zero-sized record in between, which is what happens to a deleted file.

The second version of the code you posted looks just right, except of course that it should check on /drive1 for any file it doesn't find on /drive0.

Peter